home *** CD-ROM | disk | FTP | other *** search
Text File | 1997-08-06 | 108.0 KB | 2,692 lines |
-
-
-
-
-
-
- Network Working Group H. Berkowitz
- Request for Comments: 2072 PSC International
- Category: Informational January 1997
-
-
- Router Renumbering Guide
-
- Status of this Memo
-
- This memo provides information for the Internet community. This memo
- does not specify an Internet standard of any kind. Distribution of
- this memo is unlimited.
-
- Abstract
-
- IP addresses currently used by organizations are likely to undergo
- changes in the near to moderate term. Change can become necessary
- for a variety of reasons, including enterprise reorganization,
- physical moves of equipment, new strategic relationships, changes in
- Internet Service Providers (ISP), new applications, and the needs of
- global Internet connectivity. Good IP address management may in
- general simplify continuing system administration; a good renumbering
- plan is also a good numbering plan. Most actions taken to ease
- future renumbering will ease routine network administration.
-
- Routers are the components that interconnect parts of the IP address
- space identified by unique prefixes. Obviously, they will be
- impacted by renumbering. Other interconnection devices, such as
- bridges, layer 2 switches (i.e., specialized bridges), and ATM
- switches may be affected by renumbering. The interactions of these
- lower-layer interconnection devices with routers must be considered
- as part of a renumbering effort.
-
- Routers interact with numerous network infrastructure servers,
- including DNS and SNMP. These interactions, not just the pure
- addressing and routing structure, must be considered as part of
- router renumbering.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Berkowitz Informational [Page 1]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3. Motivations for Renumbering . . . . . . . . . . . . . . . . 3
- 4. Numbering and Renumbering. . . . . . . . . . . . . . . . . . 9
- 5. Moving toward a Renumbering-Friendly Enterprise. . . . . . . 13
- 6. Potential Pitfalls in Router Renumbering. . . . . . . . . 20
- 7. Tools and Methods for Renumbering . . . . . . . . . . . . 25
- 8. Router Identifiers . . . . . . . . . . . . . . . . . . . . . 29
- 9. Filtering and Access Control . . . . . . . . . . . . . . . . 35
- 10. Interior Routing . . . . . . . . . . . . . . . . . . . . . . 37
- 11. Exterior Routing . . . . . . . . . . . . . . . . . . . . . . 39
- 12. Network Management . . . . . . . . . . . . . . . . . . . . . 41
- 13. IP and Protocol Encapsulation . . . . . . . . . . . . . . . 43
- 14. Security Considerations. . . . . . . . . . . . . . . . . . . 44
- 15. Planning and Implementing the Renumbering . . . . . . . . . 44
- 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46
- 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
- 18. Author's Address . . . . . . . . . . . . . . . . . . . . . . 48
-
- 1. Introduction
-
- Organizations can decide to renumber part or all of their IP address
- space for a variety of reasons. Overall motivations for renumbering
- are discussed in [RFC2071]. This document deals with the router-
- related aspects of a renumbering effort, once the decision to
- renumber has been made.
-
- A renumbering effort must be well-planned if it is to be successful.
- This document deals with planning and implementation guidelines for
- the interconnection devices of an enterprise. Of these devices,
- routers have the clearest association with the IP numbering plan.
-
- Planning begins with understanding the problem to be solved. Such
- understanding includes both the motivation for renumbering and the
- technical issues involved in renumbering.
-
- 1. Begin with a short and clear statement of the reason to
- renumber. Section 3 of this document discusses common
- reasons.
-
- 2. Understand the principles of numbering in the present and
- planned environments. Section 4 reviews numbering and
- suggests a method for describing the scope of renumbering.
-
-
-
-
-
-
- Berkowitz Informational [Page 2]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- 3. Before the actual renumbering, it can be useful to evolve
- the current environment and current numbering to a more
- "renumbering-friendly" system. Section 5 discusses ways to
- introduce renumbering friendliness into current systems.
-
- 4. Be aware of potential pitfalls. These are discussed in
- Section 6.
-
- 5. Identify potential requirements for tools, discussed in
- Section 7.
-
- 6. Evaluate the specific router mechanisms that will be affected
- by renumbering. See Sections 8 through 13.
-
- 7. Set up a specific transition plan framework. Guidelines
- for such planning are in Section 15.
-
- When trying to understand the interactions of renumbering on routers,
- remember there different aspects to the problem, depending on the
- scope of the renumbering involved. Remember that even an
- enterprise-wide renumbering probably will not affect all IP addresses
- visible within the enterprise, since some addresses (e.g., Internet
- service providers, external business partners) are outside the
- address space under the control of the enterprise.
-
- 2. Disclaimer
-
- The main part of this document is intended to be vendor-independent.
- Not all features discussed, of course, have been implemented on all
- routers. This document should not be used as a general comparison
- of the richness of features of different implementations.
- References here are only to those features affected by renumbering.
- Some illustrative examples may be used that cite vendor-specific
- characteristics. These examples do not necessarily reflect the
- current status of products.
-
- 3. Motivations for Renumbering
-
- Reasons to renumber can be technological, organizational, or both.
- Technological reasons fall into several broad categories discussed
- below. Just as there can be both technological and organizational
- motivations for renumbering [RFC2071], there can be multiple
- technological reasons.
-
- There may not be a clear line between organizational and technical
- reasons for renumbering. While networks have a charm and beauty all
- their own, the organizational reasons should be defined first in
- order to justify the budget for the technical renumbering. There
-
-
-
- Berkowitz Informational [Page 3]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- also may be pure technnical reasons to renumber, such as changes in
- technology (e.g., from bridging to routing).
-
- While this document is titled "Router Renumbering Guide," it
- recognizes that renumbering may be required due to the initial
- installation of routers in a bridged legacy network. Organizations
- may have had an adequate bridging solution that did not scale with
- growth. Some organizations could not able to move to routers until
- router forwarding performance improved [Carpenter] to be comparable
- to bridges.
-
- Other considerations include compliance with routing outside the
- organization. Routing issues here are primarily those of the global
- Internet, but may also involve bilateral private links to other
- enterprises.
-
- Certain new transmission technologies have tended to redefine the
- basic notion of an IP subnet. The numbering plan needs to work with
- these new ideas. Legacy bridged networks and leading-edge workgroup
- switched networks may very well need changes in the subnetting
- structure. Renumbering needs may also develop with the introduction
- of new WAN technologies, especially nonbroadcast multiaccess (NBMA)
- services such as frame relay. Other WAN technologies, dialup media
- using modems or ISDN, also may have new routing and numbering
- requirements. Switched virtual circuit services such as ATM, X.25,
- or switched frame relay also interact with routing and addressing.
-
- 3.1 Internet Global Routing
-
- Many discussions of renumbering emphasize interactions among
- organizations' numbering plans and those of the global Internet
- [RFC1900]. There can be equally strong motivations for renumbering
- in organizations that never connect to the global Internet.
-
- According to RFC1900, "Unless and until viable alternatives are
- developed, extended deployment of Classless Inter-Domain Routing
- (CIDR) is vital to keep the Internet routing system alive and to
- maintain continuous uninterrupted growth of the Internet....To
- contain the growth of routing information, whenever such an
- organization changes to a new service provider, the organization's
- addresses will have to change.
-
- Occasionally, service providers themselves may have to change to a
- new and larger block of address space. In either of these cases, to
- contain the growth of routing information, the organizations
- concerned would need to renumber.... If the organization does not
- renumber, then some of the potential consequences may include (a)
- limited (less than Internet-wide) IP connectivity, or (b) extra cost
-
-
-
- Berkowitz Informational [Page 4]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- to offset the overhead associated with the organization's routing
- information that Internet Service Providers have to maintain, or
- both."
-
- 3.2 Bridge Limitations; Internal Use of LAN Switching
-
- Introducing workgroup switches may introduce subtle renumbering
- needs. Fundamentally, workgroup switches are specialized, high-
- performance bridges, which make their main forwarding decisions
- based on Layer 2 (MAC) address information. Even so, they rarely
- are independent of Layer 3 (IP) address structure. Pure Layer 2
- switching has a "flat" address space that will need to be renumbered
- into a hierarchical, subnetted space consistent with routing.
- Traditional bridged networks share many of the problems of workgroup
- switches, but have additional performance problems when bridged
- connectivity extends across slow WAN links.
-
- Introducting single switches or stacks of switches may not have
- significant impact on addressing, as long as it is remembered that
- each system of switches is a single broadcast domain. Each broadcast
- domain should map to a single IP subnet.
-
- Virtual LANs (VLAN) further extend the complexity of the role of
- workgroup switches. It is generally true that moving an end station
- from one switch port to another within the same "color" VLAN will not
- cause major changes in addressing. Many discussions of this
- technology do not make it clear that moving the same end station
- between different colors will move the end station into another IP
- subnet, requiring a significant address change.
-
- Switches are commonly managed by SNMP applications. These network
- management applications communicate with managed devices using IP.
- Even if the switch does not do IP forwarding, it will itself need IP
- addresses if it is to be managed. Also, if the clients and servers
- in the workgroup are managed by SNMP, they will need IP addresses.
- The workgroup, therefore, will need to appear as one or more IP
- subnets.
-
- Increasingly, internetworking products are not purely Layer 2 or
- Layer 3 devices. A workgroup switch product often includes a router
- function, so the numbering plan must support both flat Layer 2 and
- hierarchical Layer 3 addresses.
-
-
-
-
-
-
-
-
-
- Berkowitz Informational [Page 5]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- 3.3 Internal Use of NBMA Cloud Services
-
- "Cloud" services such as frame relay often are more economical than
- traditional services. At first glance, when converting existing
- enterprise networks to NBMA, it might appear that the existing subnet
- structure should be preserved, but this is often not the case.
-
- Many organizations often began by treating the "cloud" as a single
- subnet, but experience has shown it is often better to treat the
- individual virtual circuits as separate subnets. When the individual
- point-to-point VCs become separate subnets, efficient address
- utilization requires the use of /30 prefixes for these subnets. This
- typically means the addressing and routing plan must support multiple
- prefix lengths, establishing one or more prefix lengths for LAN media
- with more than two hosts, and subdividing one or more of these
- shorter prefixes into longer /30 prefixes that minimize address loss.
-
- There are alternative ways to configure routing over NBMA, using
- special mechanisms to exploit or simulate point-to-multipoint VCs.
- These often have a significant performance impact on the router, and
- may be less reliable because a single point of failure is created.
- Mechanics of these alternatives are discussed later in this section,
- but the motivations for such alternatives tend to include:
-
- 1. A desire not to use VLSM. This is often founded in fear
- rather than technology.
- 2. Router implementation issues that limit the number of subnets
- or interfaces a given router can support.
- 3. An inherently point-to-multipoint application (e.g., remote
- hosts to a data center). In such cases, some of the
- limitations are due to the dynamic routing protocol in use.
- In such "star" applications, static routing may actually be
- preferable from performance and flexibility standpoints,
- since it does not produce routing traffic and is unaffected
- by split horizon.
-
- To understand how use of NBMA services affects the addressing
- structure and routers, it is worth reviewing what would appear to be
- very basic concepts of IP subnets. The traditional view is that a
- single subnet is associated with a single physical medium. All hosts
- physically connected to this medium are assumed to be able to reach
- all other hosts on the same medium, using data link level services.
- These services are medium specific: hosts connected to a LAN medium
- can broadcast to one another, while hosts connected to a point-to-
- point line simply need to transmit to the other end.
-
-
-
-
-
-
- Berkowitz Informational [Page 6]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- When one host desires to transmit to another, it first determines if
- the destination is local or remote. A local destination is on the
- same subnet and assumed to be reachable through data link services.
- A remote destination is on a different subnet, and it is assumed that
- router intervention is needed to reach it.
-
- The first NBMA problem comes up when a single subnet is implemented
- over an NBMA service. Frame Relay provides single virtual circuits
- between hosts that have connectivity. It is quite common to design
- Frame Relay services as partial meshes, where not all hosts have VCs
- to all others. When the set of hosts in a partial mesh is in a
- single IP subnet, partial mesh violates the local model of full
- connectivity. Even when there is full meshing, a pessimistic but
- reasonable operational model must consider that individual VCs do
- fail, and full connectivity may be lost transiently.
-
- There are several ways to deal with this violation, each with their
- own limitations. If a specific "central" host has connectivity to N
- all other hosts, that central host can replicate all frames it
- receives from one host onto outgoing VCs connecting it with the (N-1)
- other hosts in the subnet. Such replication usually causes an
- appreciable CPU load in the replicating router. The replicating
- router also is a single point of failure for the subnet. This method
- does not scale well when extended to fuller meshes within the subnet.
-
- In a routing protocol, such as OSPF, that has a concept of designated
- routers, explicit configuration usually is needed. Other problems in
- using a meshed subnet is that all VCs may not have the same
- performance, but the router cannot prefer individual paths within the
- subnet.
-
- One of the simplest methods is not to attempt to emulate a broadcast
- medium, but simply to treat each VC as a separate subnet. This will
- cause a need for renumbering. Efficient use of the address space
- dictates a /30 prefix be used for the per-VC subnets. Such a prefix
- often needs VLSM support in the routers.
-
- 3.4 Expansion of Dialup Services
-
- Dialup services, especially public Internet access providers, are
- undergoing explosive growth. This success represents a particular
- drain on the available address space, especially with a commonly used
- practice of assigning unique addresses to each customer.
-
-
-
-
-
-
-
-
- Berkowitz Informational [Page 7]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- In this practice, individual users announce their address to the
- access server using PPP's IP configuration option [RFC1332]. The
- server may validate the proposed address against some user
- identifier, or simply make the address active in a subnet to which
- the access server (or set of bridged access servers) belongs.
-
- These access server functions may be part of the software of a
- "router" and thus are within the scope of this Guide.
-
- The preferred technique [Hubbard] is to allocate dynamic addresses to
- the user from a pool of addresses available to the access server.
- Various mechanisms are used actually to do this assignment, and are
- discussed in Section 5.5.
-
- 3.5 Internal Use of Switched Virtual Circuit Services
-
- Services such as ATM virtual circuits, switched frame relay, etc.,
- present challenges not considered in the original IP design. The
- basic IP decision in forwarding a packet is whether the destination
- is local or remote, in relation to the source host's subnet. Address
- resolution mechanisms are used to find the medium address of the
- destination in the case of local destinations, or to find the medium
- address of the router in the case of remote routers.
-
- In these new services, there are cases where it is far more effective
- to "cut-through" a new virtual circuit to the destination. If the
- destination is on a different subnet than the source, the cut-through
- typically is to the egress router that serves the destination subnet.
-
- The advantage of cut-through in such a case is that it avoids the
- latency of multiple router hops, and reduces load on "backbone"
- routers. The cut-through decision is usually made by an entry router
- that is aware of both the routed and switched environments.
-
- This entry router communicates with a address resolution server using
- the Next Hop Resolution Protocol (NHRP) [Cansever] [Katz]. This
- server maps the destination network address to either a next-hop
- router (where cut-through is not appropriate) or to an egress router
- reached over the switched service. Obviously, the data base in such
- a server may be affected by renumbering. Clients may have a hard-
- coded address of the server, which again may need to change.
-
- While the NHRP work is in progress at the time of this writing,
- commercial implementations based on drafts of the protocol standard
- are in use.
-
-
-
-
-
-
- Berkowitz Informational [Page 8]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- 4. Numbering and Renumbering
-
- What is the role of any numbering plan? To understand the general
- problem, it can be worthwhile to review the basic principles of
- routers. While most readers will have a good intuitive sense of
- this, the principles have refined in the current usage of IP.
-
- A router receives an inbound IP datagram on one of its interfaces,
- and examines some number of bits of the destination address. The
- sequence of bits examined by the router always begin at the left of
- the address (i.e., the most significant bit). We call this sequence
- a "prefix."
-
- Routing decisions are made on totalPrefix bits, which start at the
- leftmost (i.e., most significant) bit position of the IP address.
- Those totalPrefix bits may be completely under the control of the
- enterprise (e.g., if they are in the private address space), or the
- enterprise may control the lowOrderPrefix bits while the
- highOrderPrefix bits are assigned by an outside organization.
-
- The router looks up the prefix in its routing table (formally called
- a Forwarding Information Base). If the prefix is in the routing
- table, the router then selects an outgoing interface that will take
- the routed packet to the next hop IP address in the end-to-end route.
- If the prefix cannot be found in the routing table, the router
- returns an ICMP Destination Unreachable message to the source address
- in the received datagram.
-
- Assuming the prefix is found in the routing table, the router then
- transmits the datagram through the indicated outgoing interface. If
- multicast routing is in effect, the datagram may be copied and sent
- out multiple outgoing interfaces.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Berkowitz Informational [Page 9]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- 4.1 Categorizing the topology
-
- From the router renumbering perspective, renumbering impact is apt to
- be greatest in highly connected parts of "backbones," and least in
- "stub" parts of the routing domain that have a single route to the
- backbone.
-
- Global Internet
- ^
- |
- |
- Back1-------------------Back2
- | |
- +-----------+ +----------+
- | | | |
- Reg1.1------Reg1.2 Reg2.1-----Reg2.2
- | | | |
- | | | |
- Branch Branch Branch Branch
- 1.1.1 to 1.2.1 to 2.1.1 to 2.2.1 to
- 1.1.N 1.2.N 2.1.N 2.2.N
-
- In this drawing, assume Back1 and Back2 exchange full routes; Back1
- is also the exterior router. Regional routers (Reg) exchange full
- routes with one another and aggregate addresses to the backbone
- routers. Branch routers default to regional routers.
-
- From a pure topological standpoint, the higher in the hierarchy, the
- greater are apt to be the effects of renumbering. This is a first
- approximation to scoping the task, assuming addresses have been
- assigned systematically. Systematic address space is rarely the case
- in legacy networks.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Berkowitz Informational [Page 10]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- 4.2 Categorizing the address space
-
- An inventory of present and planned address space is a prerequisite
- to successful renumbering. Begin by identifying the prefixes in or
- planned into your network, and whether they have been assigned in a
- systematic and hierarchical manner.
-
- +--Unaffected by renumbering [A]
- |
- |
- +--Existing prefixes to be renumbered
- | |
- | |
- | +----To be directly renumbered on "flag day"
- | |
- | |
- | +----Initially to be renumbered to temporary address
- |
- |
- +--Existing prefixes to be retired
- |
- |
- +--Planned new prefixes
- |
- |
- +---totalPrefix change, no length change
- |
- |
- +---highOrderPart change only, no length change
- |
- |
- +---lowOrderPart change only, no length change
- |
- |
- +---highOrderPart change only, high length change
- |
- |
- +---lowOrderPart change only, low length change
- |
- |
- +---totalPrefix change only, changes in high and low
- |
- |
- +---highOrderPart change only, no length change
-
- Ideally, a given prefix should either be "unchanged," "old," or
- "new." Renumbering will be easiest when each "old" prefix can be
- mapped to a single "new" prefix.
-
-
-
- Berkowitz Informational [Page 11]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- Unfortunately, the ideal often will not be attainable. It may be
- necessary to run parts of the new and old address spaces in parallel.
-
- Renumbering applies first to prefixes and then to host numbers to the
- right of the prefix. To understand the scope of renumbering, it is
- essential to:
-
- 1. Identify the prefixes (and possibly host fields) potentially
- affected by the renumbering operation.
-
- 2. Identify the authority that controls the values of the prefix,
- or part of the prefix, affected by renumbering.
-
- In a given enterprise, prefixes may be present that will be under the
- complete or partial control of the enterprise, as well as totally
- outside the control of the enterprise. Let us review the principles
- of control over address space.
-
- More commonly, the most significant bits of the prefix are assigned
- to the enterprise by an address registry (e.g., InterNIC, RIPE, or
- APNIC) or by an Internet Service Provider (ISP). This assignment of
- a value in the most significant bit positions historically has been
- called a "network number," when the assigned high-order part is 8,
- 16, or 24 bits long. More recent usage does not limit the assigned
- part to a byte boundary. The preferred term for the assigned part is
- a "CIDR block" of a certain number of bits [RFC1518].
-
- The enterprise then extends the prefix to the right, creating
- "subnets." It is critical to realize that routers make routing
- decisions based on the total prefix of interest, regardless of who
- controls which bits. In other words, the router really doesn't know
- or care about subnet boundaries.
-
- The way to think about subnetting is that it creates a longer prefix.
- Even before CIDR, we collapsed multiple subnets into a single network
- number advertisement sent to external routers. In a more general
- way, we now think of extending the prefix to the right as subnetting
- and collapsing it to the left as supernetting, aggregating, or
- summarizing. Depending on the usage of subnetting or aggregation,
- different prefix lengths are significant at different router
- interfaces.
-
- 4.3 Renumbering Scope
-
- Prefixes may be taken from the private address space [RFC1918] that
- is not routable on the global Internet. Since these addresses are
- not routable on the global Internet, changing parts of private
- address space prefixes is an enterprise-local decision.
-
-
-
- Berkowitz Informational [Page 12]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- If a prefix is totally outside the control of the enterprise, it is
- external, and will be minimally affected by routing. Potential
- interactions of external prefixes with enterprise renumbering
- include:
-
- 1) Inadvertent alteration or deletion of external addresses
- as part of router reconfiguration.
- 2) Loss of connectivity to application servers inside the
- enterprise, because the external client no longer knows
- the internal address of the server.
- 3) DNS/BGP
- 4) Security
-
- Prefixes partially under the control of the enterprise may change.
- The scope of this will vary depending on whether only the externally
- controlled part of the prefix changes, or if part of the internally
- controlled part is to be renumbered. If the length of either the
- high-order or low-order parts change, the process becomes more
- complex.
-
- High-order-part-only renumbering is most common when an organization
- changes ISPs, and needs to renumber into the new provider's space.
- The old prefix may have been assigned to the enterprise but will no
- longer be used for global routing, or the old prefix may have been
- assigned to the previous provider. Note that administrative
- procedures may be necessary to return the previous prefix, although
- this usually will be done by the previous provider. There often will
- need to be a period of coexistence between the old and new prefixes.
-
- Low-order-part-only renumbering can occur when an enterprise modifies
- its internal routing structure, and the changes only affect the
- internal subnet structure of the enterprise network. This is typical
- of efforts involved in increasing the number of available subnets
- (e.g., for more point-to-point media) or increasing the number of
- hosts on a medium (e.g., in greater use of workgroup switches).
-
- Both the high-order and low-order parts may change. This might
- happen when the enterprise changes to a new ISP, who assigns address
- space from a CIDR block rather than a classful network previously
- used. With a different high-order prefix length, the enterprise
- might be forced to change its subnet structure.
-
- 5. Moving toward a Renumbering-Friendly Enterprise
-
- Renumbering affects both the configuration of specific router
- "boxes," and the overall system of routers in a routing domain. The
- emphasis of this section is on making the current enterprise more
- renumbering-friendly, before any prefixes are actually changed.
-
-
-
- Berkowitz Informational [Page 13]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- Renumbering will have the least impact when the minimum number of
- reconfiguration options are needed. When planning renumbering on
- routers, consider that many existing configurations may contain
- hard-coded IP addresses that may not be necessary, even if
- renumbering were not to occur. Part of a router renumbering effort
- should include, wherever possible, replacing router mechanisms based
- on hard-coded addresses with more flexible mechanisms.
-
- Renumbering will also generally be easier if the configuration
- changes can be made offline on appropriate servers, and then
- downloaded to the router if the router implementation permits.
-
- 5.1 Default Routes
-
- A well-known method for reducing the amount of reference by one
- router to other routers is to use a default route to a higher-level,
- better-connected router. This assumes a hierarchical network design,
- which is generally desirable in the interest of scaling.
-
- Default routes are most appropriate for stub routers inside a routing
- domain, and for boundary routers that connect the domain to a single
- ISP.
-
- 5.2 Route Summarization and CIDR
-
- When routes need to be advertised, summarize as much as is practical.
- Summarization is most effective when address prefixes have been
- assigned in a consistent and contiguous manner, which is often not
- the case in legacy networks. Nevertheless, there is less to change
- when we can refer to blocks of prefixes.
-
- Not all routing mechanisms support general summarization. Interior
- routing mechanisms that do include RIPv2, OSPF, EIGRP, IS-IS, and
- systems of static routes. RIPv1 and IGRP do support classful
- summarization (i.e., at Class A/B/C network boundaries only).
-
- If existing addresses have been assigned hierarchically, it may be
- possible to renumber below the level of summarization, while hiding
- the summarization to the rest of the network. In other words, if all
- the address bits being renumbered are to the right of the summarized
- prefix length, the change can be transparent to the overall routing
- system.
-
- Even when effective summarization is possible to hide the details of
- routing, DNS, filters, and other services may be affected by any
- renumbering.
-
-
-
-
-
- Berkowitz Informational [Page 14]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- 5.3 Server References in Routers
-
- Routers commonly communicate with an assortment of network management
- and other infrastructural servers. Examples of these servers are
- given in the "Network Management" section below. DNS itself,
- however, may be an important exception.
-
- Wherever possible, servers should be referenced by DNS name rather
- than by IP address. If a specific router implementation only
- supports explicit address references, this should be documented as
- part of the renumbering plan.
-
- Routers may also need to forward end host broadcasts to other
- infrastructure services (e.g., DNS, DHCP/BOOTP). Configurations that
- do this are likely to contain hard-coded IP addresses of the
- destination hosts or their subnets, which will need to be changed as
- part of renumbering.
-
- 5.4 DNS and Router Renumbering
-
- The Domain Name Service is a powerful tool in any renumbering effort,
- and can help routers as well as end hosts. If traceroute displays
- DNS names rather than IP addresses, certain debugging options can be
- transparent through the address transition.
-
- Be aware that dynamically learned names and addresses may be cached
- in router tables. For a router to learn changes in address to name
- correspondence, it may be necessary to restart the router or
- explicitly clear the cache.
-
- Alternatively, router configuration files may contain hard-coded
- address/name correspondences that will not be affected by a change in
- the DNS server.
-
- Different DNS databases are affected by renumbering. For example,
- the enterprise usually controls its own "forward" data base, but the
- reverse mapping data base may be maintained by its ISP. This can
- require coordination when changing providers.
-
- Commonly, router renumbering goes through a transition period.
- During this transition, old and new addresses may coexist in the
- routing system. Coexistence over a significant period of time is
- especially likely for DNS references to addresses that are known in
- the global Internet [deGroot]. Various DNS servers throughout the
- world may cache addresses for periods of days.
-
-
-
-
-
-
- Berkowitz Informational [Page 15]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- If, for example, a given router interface may have a coexisting new
- and old address, it can be appropriate to introduce the new address
- as an additional A record for the new address.
-
- DNS RR statements can end with a semicolon, indicating the rest of
- the line is a comment. This can be used as the basis of tools to
- renumber DNS names for router addresses, by putting a comment (e.g.,
- ";newaddr") at the end of the A statements for the new addresses. At
- an appropriate time, a script could generate a new zone file in which
- the new addresses become the primary definitions on A records, and
- the old addresses could become appropriately commented A records. At
- a later time, these commented entries could be removed.
-
- Care should be taken to assure that PTR reverse mapping entries are
- defined for new addresses, because some router vendor tools depend on
- reverse mapping.
-
- 5.5 Dynamic Addressing
-
- Renumbering is easiest when addresses need to be changed in the least
- possible number of places. Dynamic address assignment is especially
- attractive for end hosts, and routers may play a key role in this
- process. Routers may act as servers and actually assign addresses,
- or may be responsible for forwarding end host address assignment
- requests to address assignment servers.
-
- The most common use of dynamic address assignment is to provide IP
- addresses to end systems. Dynamic address assignment, however, is
- also used to assign IP addresses to router interfaces. An address
- assignment server may assign an IP address to a router either in the
- usual DHCP way, based on a MAC address in the router, or simply based
- on the physical connectivity of the new router. In other words, any
- router connected on a specific interface of the configuring router
- would be assigned the same IP address.
-
- 5.5.1 Router Roles in LAN-based DHCP Address Assignment
-
- End hosts attached to LANs often obtain address assignments from
- BOOTP or DHCP servers. If the server is not on the same medium as
- the end hosts, routers may need to play a role in establishing
- connectivity between the end host and the address server.
-
- If the client is not on the same medium as the address assignment
- server, routers either must act as address assignment services, or
- forward limited broadcasts to the location of appropriate servers.
-
-
-
-
-
-
- Berkowitz Informational [Page 16]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- If the router acts as an address assignment server, its database of
- addresses that it can assign may change during renumbering. If the
- router forwards to a DHCP or BOOTP server, it must know the address
- of that server. That server address can itself change as a result of
- renumbering.
-
- While the usual perception of DHCP is that it assigns addresses from
- a pool, such that assignments to a given host at a given time is
- random within the pool, DHCP can also return a constant IP address
- for a specific MAC address. This may be much easier to manage and
- troubleshoot, especially during renumbering.
-
- Clearly, if the DHCP server identifies end hosts based on their MAC
- address, consideration must be given to making that address unique,
- and changing the DHCP database if either the MAC address or the IP
- address changes. One way to reduce such reconfiguration is to use
- Locally-Administered Addresses (LAA) on end hosts, rather than
- globally unique addresses stored in read-only memory (ROM). Using
- LAAs solves the problem of MAC addresses changing when a network
- interface card changes, but LAAs have their own management problems
- of configuration into end systems and maintaining uniqueness within
- the enterprise.
-
- 5.5.2 Router Roles in Dialup Address Assignment
-
- There are several possible ways in which an dialup end host interacts
- with address assignment. Routers/access servers can play critical
- roles in this process, either to provide connectivity between client
- and server, or directly to assign addresses.
-
- Different vendors handle address assignment in different ways.
- Methods include:
-
- 1. The access server forwards the request to a DHCP server, using
- a unique 48-bit identifier associated with the client. Note
- that this usually should not be the MAC address of the access
- server, since the same MAC address would then be associated
- with different hosts.
-
- 2. The server forwards the request to an authentication server,
- which in turn gets a dynamic address either from:
-
- a. internal pools
- b. a DHCP server to which it forwards
-
- 3. The server selects an address from locally configured pools
- and provides it to the dialing host without the intervention
- of other services.
-
-
-
- Berkowitz Informational [Page 17]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- When the router contains assignable addresses, these may need to
- change as part of renumbering. Alternatively, hard-coded references
- to address assignment or authentication servers may need to change.
-
- 5.5.3 Router Autoonfiguration
-
- This initial address assignment may provide an address only for a
- single connection (i.e., between the new and configuring routers).
- The newly assigned address may then be used to "bootstrap" a full
- configuration into the new router.
-
- Dynamic address assignment to routers is probably most common at
- outlying "stub" or "edge" routers that connect via WAN links to a
- central location with a configuration server. Such edge devices may
- be shipped to a remote site, plugged in to a WAN line, and use
- proprietary methods to acquire part or all of their address
- configuration.
-
- When such autoconfiguration is used on edge routers, it may be
- necessary to force a restart of the edge router after renumbering.
- Restarting may be the only way to force the autoconfigured router to
- learn its new address. Other out-of-band methods may be available to
- change the edge router addresses.
-
- 5.6 Network Address Translation
-
- Network address translation (NAT) is a valuable technique for
- renumbering, or even for avoiding the need to renumber significant
- parts of an enterprise [RFC1631]. It is not always transparent to
- network layer protocols, upper layer protocols, and network
- management tools, and must not be regarded as a panacea.
-
- In the classic definition of NAT, certain parts of the routing system
- are designated as stub domains, and connect to the global domain only
- through NAT functions. The NAT contains a translation mechanism that
- maps a stub address to a global address. This mechanism may map
- statically or dynamically.
-
- A more general NAT mechanism often is implemented in firewall bastion
- hosts, which isolate "inside" and "outside" addresses through
- transport- or application-level authenticated gateways. Mappings
- from a "local" or "inside" address to a global address often is not
- one-to-one, because an inside address is dynamically mapped to a TCP
- or UDP port on an outside interface address.
-
- In general, if there are multiple NATs, their translation mechanisms
- should be synchronized. There are specialized cases when a given
- stub address appears in more than one stub domain, and ambiguity
-
-
-
- Berkowitz Informational [Page 18]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- develops if one wishes to map, say, from 10.1.0.1/16 in stub domain A
- to 10.1.0.1/16 in stub domain B. In this case, both 10.1.0.1
- addresses identify different hosts. Special mechanisms would have
- to exist to map the domain A local address into one global address,
- and to map the domain B local address into a different global
- address.
-
- NAT can have a valuable role in renumbering. Its intelligent use can
- greatly minimize the amount of renumbering that needs to be done.
- NAT, however, is not completely transparent.
-
- Specifically, it can interfere with the proper operation of any
- protocol that carries an IP address as data, since NAT does not
- understand passenger fields and is unaware numbers need to change.
-
- Examples of protocols affected are:
-
- --TCP and UDP checksums that are in part based on the
- IP header. This includes end-to-end encryption schemes
- that include the TCP/UDP checksum
- --ICMP messages containing IP addresses
- --DNS queries that return addresses or send addresses
- --FTP interactions that use an ASCII-encoded IP address
- as part of the PORT command
-
- It may be possible to avoid conflict if only certain hosts use
- affected protocols. Such hosts could be assigned only global
- addresses, if the network topology and routing plan permit.
-
- Early NAT experiments suggested that it needs a sparse end-to-end
- traffic mapping database for reasonable performance. This may or may
- not be an issue in more hardware-based NAT implementations.
-
- Another concern with NAT is that unique host addresses are hidden
- outside the local stub domains. This may in fact be desirable for
- security, but may present network management problems. One
- possibility would be to develop a NAT MIB that could be queried by
- SNMP to find the specific local-to-global mappings in effect.
-
- There are also issues for DNS, DHCP, and other address management
- services. There presumably would need to be local servers within
- stub domains, so address requests would be resolved uniquely in each
- stub (or would return appropriate global addresses).
-
-
-
-
-
-
-
-
- Berkowitz Informational [Page 19]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- 6. Potential Pitfalls in Router Renumbering
-
- One way to categorize potential pitfalls is to look at those
- associated with the overall numbering plan itself and routing
- advertisement, and those associated with protocol behavior. In
- general, the former case is static and the latter is dynamic.
-
- 6.1 Static
-
- Problems can be implicit to the address/routing structure itself.
- These can include failures of components to understand arbitrary
- prefix addressing (i.e., classless routing), reachability due to
- inappropriate default or aggregated routes, etc.
-
- 6.1.1 Classless Routing Considerations
-
- Among the major reasons to renumber is to gain globally routable
- address space. In the global Internet, routable address space is
- based on arbitrary-length prefixes rather than traditional address
- classes. Classless Inter-Domain Routing (CIDR) is the administrative
- realization of prefix addressing in the global Internet. Inside
- enterprises, arbitrary prefix length addressing often is called
- Variable Length Subnet Masking (VLSM) or "subnetting a subnet."
-
- The general rules of prefix addressing must be followed in CIDR.
- Among these are permitting use of the all-zeroes and all-one subnets
- [RFC1812], and not assuming that a route to a "Class A/B/C network
- number" implies routes to all subnets of that network. Assumptions
- also should not be made that a prefix length is implied by the
- structure of the high-order bits of the IP address (i.e., the "First
- Octet Rule").
-
- This ideal, unfortunately, is not understood by a significant number
- of routers (and terminal access servers that participate in routing),
- and an even more significant number of host IP implementations.
-
- When planning renumbering, network designers must know if the new
- address has been allocated using CIDR rules rather than traditional
- classful addressing. If CIDR rules have been followed in address
- assignment, then steps need to be taken to assure the router
- understands them, or appropriate steps need to be taken to interface
- the existing environment to the CIDR environment.
-
- Current experience suggests that it is best, when renumbering, to
- maintain future compatibility by moving to a CIDR-supportive routing
- environment. While this is usually thought to mean introducing a
- classless dynamic routing protocol, this need not mean that routing
- become much more complex. In a RIPv1 environment, moving to RIPv2
-
-
-
- Berkowitz Informational [Page 20]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- may be a relatively simple change. Alternative simple methods
- include establishing a default route from a non-CIDR-compliant
- routing domain to a CIDR-compliant service provider, or making use of
- static routes that are CIDR-compliant.
-
- Some routers support classless routing without further
- configuration, other routers support classless routing but require
- specific configuration steps to enable it, while other routers only
- understand classful routing. In general, most renumbering will
- eventually require classless routing support. It is essential to
- know if a given router can support classless routing. If it does
- not, workarounds may be possible. Workarounds are likely to be
- necessary.
-
- 6.1.1.1 Aggregation Problems
-
- In experimenting with the CIDR use of a former Class A network
- number, it was shown in RFC1879 that CIDR compliance rules must be
- enabled explicitly in some routers, while other routers do not
- understand CIDR rules.
-
- RFC 1897 demonstrated problems with some existing equipment,
- especially "equipment that depends on use of a classful routing
- protocol, such as RIPv1 are prone to misconfiguration. Tested
- examples are current Ascend and Livingston gear, which continue to
- use RIPv1 as the default/only routing protocol. RIPv1 use will
- create an aggregate announcement.... The Ascend was told to announce
- 39.1.28/24, but since RIPv1 can't do this, the Ascend instead sent
- 39/8." RIPv1, like all classful interior protocols, is obsolescent.
-
- 6.1.1.2 Discontiguous Networks
-
- Another problem that can occur with routers or routing mechanisms
- that do not understand arbitrary length prefix addressing is that of
- discontiguous networks. This problem is easy to create
- inadvertently when renumbering. In the example below, assume the
- enterprise has been using 10.0.0.0/8 as its primary prefix, but has
- introduced an ISP whose registered addresses were in 172.31.0.0/16.
-
-
-
-
-
-
-
-
-
-
-
-
-
- Berkowitz Informational [Page 21]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- Assume a RIPv1 system of three routers:
-
- 10.1.0.1/16 10.2.0.1/16
- | |
- | |
- +-------------------------------------+
- | Router 1 |
- +-------------------------------------+
- | 172.31.1.1/24
- |
- |
- | 172.31.1.2/24
- +-------------------------------------+
- | Router 2 |<------OUTSIDE
- +-------------------------------------+
- | 172.31.2.1/24
- |
- |
- | 172.31.2.2/24
- +-------------------------------------+
- | Router 3 |
- +-------------------------------------+
- | |
- | |
- 10.3.0.1/16 10.4.0.1/16
-
- Router 1 can reach its two locally connected subnets, 10.1.0.0/16 and
- 10.2.0.0/16. It will aggregate them into a single announcement of
- 10.0.0.0/8 when it advertises out the 172.31.1.1 interface.
-
- In like manner, Router 3 can reach its two locally connected subnets,
- 0.3.0.0/16 and 10.4.0.0/16. It will aggregate them into a single
- announcement of 10.0.0.0/8 when it advertises out the 172.31.2.2
- interface.
-
- When Router 2 receives a packet from its "outside" interface
- destined, say, to 10.1.1.56/16, where does it send it? Router 2 has
- received two advertisements of 10.0.0.0 on different interfaces,
- without any detail of subnets inside 10.0.0.0. Router 2 has an
- ambiguous routing table in terms of the next hop to a subnet of
- 10.0.0.0. We call this problem, when parts of the same classful
- network are separated by different networks, discontigous subnets.
-
- Two problems occur in this configuration. Router 2 does not know
- where to send outside packets destined for a subnet of 10.0.0.0.
- Connectivity, however, also will break between Routers 1 and 3,
- because Router 2 does not know the next hop for any subnet of
- 10.0.0.0.
-
-
-
- Berkowitz Informational [Page 22]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- There are several workarounds to this problem. Obviously, one would
- be to change to a routing mechanism that does advertise subnets. An
- alternative would be to establish an IP-over-IP tunnel through Router
- 2, and give this a subnet in 10.0.0.0. This additional subnet would
- be visible only in Routers 1 and 3. It would solve the connectivity
- problem between Routers 1 and 3, but Router 2 would still not be able
- to forward outside packets. This might be a perfectly acceptable
- solution if Router 2 is simply being used to connect two parts of
- 10.0.0.0.
-
- Another way to deal with the discontiguous network problem is to
- assign secondary addresses in 10.0.0.0 to the R1-R2 and R2-R3
- interfaces, which would allow the 10.0.0.0 subnets to be advertised
- to R2. This would work as long as there is no problem in advertising
- the 10.0.0.0 subnets into the R2 routing system. There would be a
- problem, for example, if the 10.0.0.0 address were in the private
- address space but the R2 primary addresses were registered, and R2
- advertised the 10.0.0.0 addresses to the outside.
-
- This problem can be handled if R2 has filtering mechanisms that can
- selectively block 10.0.0.0 advertisements to the outside world. The
- configuration, however, will become more and more complicated.
-
- 6.1.1.3 Router-Host Interactions
-
- The situation may not be as bleak if hosts do not understand prefix
- addressing but routers do. Methods exist for hiding a VLSM structure
- from end hosts that do not understand it. These do involve protocol
- mechanisms as workarounds, but the fundamental problem is hosts'
- understanding of arbitrary prefix lengths.
-
- A key mechanism is proxy ARP [Carpenter]. The basic mechanism of
- using proxy ARP in prefix-based renumbering is to have the hosts
- issue an ARP whenever they want to communicate with a destination.
- If the destination is actually on the same subnet, it will respond
- directly to the ARP. If the destination is not, the router will
- respond as if it were the destination, and the originating host will
- send the datagram to the router. Once the datagram is in the router,
- the VLSM-aware router can forward it.
-
- Many end hosts, however, will only issue an ARP if they conclude the
- destination is on their own subnet. All other traffic is sent to a
- hard-coded default router address. In such cases, workarounds may be
- needed to force the host to ARP for all destinations.
-
- One workaround involves a deliberate misconfiguration of hosts.
- Hosts that only understand default routers also are apt only to
- understand classful addressing. If the host is told its major (i.e.,
-
-
-
- Berkowitz Informational [Page 23]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- classful) network is not subnetted, even though the address plan
- actually is subnetted, this will often persuade it to ARP to all
- destinations.
-
- This also works for hosts that do not understand subnetting at all.
- An example will serve for both levels of host understanding. Assume
- the enterprise uses 172.31.0.0/16 as its major address, which is in
- the Class B format. This is actually subnetted with eight bits of
- subnetting -- 172.31.0.0/24. Individual hosts unaware of VLSM,
- however, either infer Class B from the address value, or are told
- that the subnet mask in effect is 255.255.0.0.
-
- Yet another approach that helps hosts find routers is to run passive
- RIP on the hosts, so that they hear routing updates. They assume any
- host that issues routing updates must be a router, so traffic for
- non- local destinations can be forwarded there. While RIPv1 does not
- support arbitrary prefixes, the router(s) issuing the routing updates
- may have additional capabilities that let them correctly forward such
- traffic. The priority, therefore, is to get the non-local routers to
- a router that understands the overall routing structure, and passive
- RIP may be a viable way to do this.
-
- It may be appropriate to cut over on a site-by-site basis [Lear]. In
- such an approach, some sites have VLSM-aware hosts but others do not.
- As long as the routing structure supports VLSM, workarounds can be
- applied where needed.
-
- 6.1.2 MAC Address Interactions
-
- While it is uncommon now for a router to acquire any of its interface
- addresses as a DHCP client, this may become more common. When a
- router so acquires addresses, care must be taken that the MAC address
- presented to the DHCP server is in fact unique.
-
- Modern routers usually support protocol architectures besides IP.
- Some of these architectures, notably DECnet, Banyan VINES, Xerox
- Network Services, and IPX, may modify MAC addresses of routers such
- that a given MAC address appears on more than one interface. While
- this is normally not a problem, it could cause difficulties when the
- MAC address is assumed to be unique.
-
- Other situations occur when the same MAC address can appear on more
- than one interface. There are high-availability IBM options which
- establish primary and backup instances of the same MAC address on
- different physical interfaces of 37x5 communications controllers.
-
-
-
-
-
-
- Berkowitz Informational [Page 24]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- Some end hosts running protocol stacks other than IP, notably DECnet,
- may change their MAC address from the globally assigned built-in
- address.
-
- 6.2 Dynamic
-
- Dynamic protocol mechanisms that to some extent depend on IP
- addresses may be affected by router renumbering. These include
- mechanisms that assign or resolve addresses (e.g., DHCP, DNS),
- mechanisms that use IP addresses for identification (e.g., SNMP),
- security and authentication mechanisms, etc. The listed mechanisms
- are apt to have configuration files that will be affected by
- renumbering.
-
- Another area of dynamic behavior that can be affected is caching.
- Application servers, directory functions such as DNS, etc., may cache
- IP addresses. When the router is renumbered, these servers may point
- to old addresses. Certain proxy server functions may reside on
- routers, and the router may need to be restarted to reset the cache.
-
- The endpoints of TCP tunnels terminating on routers may be internally
- identified by address/port pairs at each end. If the address
- changes, even if the port remains the same, the tunnel is likely to
- need to be reestablished.
-
- 7. Tools and Methods for Renumbering
-
- The function of a renumbering tool can be realized either as manual
- procedures as well as software. This section deals with functionality
- of hypothetical yet general renumbering tools rather than their
- implementation.
-
- General caveat: tools should know whether the environment supports
- classless addressing. If it does not, newly generated addresses
- should be checked to see they do not fall into the all-zeroes or
- all-ones subnet values.
-
- 7.1 Search Mechanisms
-
- Tools will be needed to search configuration files and other
- databases to identify addresses and names that will be affected by
- reorganization. This search should be based on the address inventory
- described above.
-
- Especially when searching for names, common search tools using
- regular expressions (e.g., grep) may be very useful. Some additional
- search tools may be needed. One would convert dotted decimal search
- arguments to binary and only then makes the comparison.
-
-
-
- Berkowitz Informational [Page 25]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- The comparison may need to be done under the constraint of a mask.
- Such a comparator would also be relevant as the second phase that
- looks for ipAddress and other relevant strings in MIBs.
-
- 7.2 Address Modification
-
- The general mechanism for address modification is substitution of an
- arbitrary number of bits in an address. In the simplest cases, there
- is a one-to-one correspondence between old and new bit positions.
-
- Especially when address modification is manual, it should be
- remembered that the affected bits can be obscured by dotted decimal
- notation. Work in, or at least consider, binary notation to assure
- accuracy.
-
- Several basic functions can be defined:
-
- zerobits(position,length):
- clear <length> bits starting at <position>
- orbits(position,length,newbits)
- OR the bit string <newbits> of <length> starting at <position>
-
- In these examples, the index [j] is used to identify entries in the
- address inventory database for existing addresses, while [k]
- identifies new addresses.
-
- Remember that these tools operate at a bit level, so the new address
- will have to be converted back into dotted decimal, MIB ASN.1, or
- other notation before it can be replaced into configuration files.
-
- 7.2.1 Prefix Change, No Change in Length
-
- If the entire new prefix has the same number of bits as the old
- external part, requiring no change to subnetting, the router part of
- renumbering may be fairly simple. If the router configurations are
- available in machine-readable form, as text files or parsable SNMP
- data, it is a relatively simple task to define a tool to examine IP
- addresses in the configuration, identify those beginning with the old
- prefix, and substitute the new prefix bit-by-bit.
-
- for each address[j],
- zerobits(0,PrefixLength[j])
- orbits(0,PrefixLength[j],NewPrefix[j])
-
- Note that the host part is unaffected. Both subnet specifications
- (e.g., for route advertisements) and specific host references will be
- changed correctly in this simple case.
-
-
-
-
- Berkowitz Informational [Page 26]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- 7.2.2 highOrderPart change
-
- Matters are slightly more complex when the change applies only to the
- externally-controlled part of the prefix, as might be the case when
- an organization changes ISPs and renumbers into the ISP's address
- space, without changing the internal subnet structure.
-
- The substitution process is much as the previous case, except only
- the high-order bits change:
-
- for each address,
- zerobits(0,highOrderPartLength[j])
- orbits(0,highOrderPartLength,newHighOrderPart[k])
-
- 7.2.3 lowOrderPart change
-
- Organizations might renumber only the lowOrderPart (i.e., the subnet
- field) of their address space. This might be done to clean up an
- address space into contiguous blocks prior to introducing a routing
- system that aggregates addresses, such as OSPF.
-
- for each address[j],
- zerobits(highOrderPartLength[j],lowOrderPartLength[j])
- orbits(highOrderPartLength[j],
- lowOrderPartLength[j],newLowOrderPart[k])
-
- 7.2.4 lowOrderPart change, Change in lowOrderPart length
-
- When the length of the subnet field changes in all or part of the
- address space, things become significantly more complex. A fairly
- simple case arises when the host field is consistently too long, at
- least in the affected subnets. This is common, for example, when
- address space is being recovered in an existing Class B network with
- 8 bits of subnetting. Certain /24 bit prefixes are being extended to
- /30 and reallocated to point-to-point real or virtual (e.g., DLCI)
- media.
-
- for each address [j]
- if address is affected by renumbering
- if newLowOrderPartLength[k] > oldLowOrderPartLength[j]
- then
- zerobits(highOrderPartLength[k],newLowOrderPartLength[k])
- orbits(highOrderPartLength[k],newLowOrderPart[k])
- end
-
-
-
-
-
-
-
- Berkowitz Informational [Page 27]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- 7.2.5 highOrderPart change, Change in highOrderPart length
-
- When the length of the high-order part changes, but it is desired to
- keep the existing subnet structure, constraints apply. The situation
- is fairly simple if the new high-order part is shorter than the
- existing high order part.
-
- If the new high-order part is longer than the old high order part,
- constraints are more complex. The key is to see if any of the <k>
- most significant bits of the oldHighOrderPart, which overlap the <k>
- least significant bits of the newHighOrderPart, are nonzero. If no
- bits are nonzero, it may be simply to overlay the new prefix bits.
-
- 7.3 Naming
-
- It is worthwhile to distinguish that a router's use of a DNS name
- does not necessarily mean that name is defined in a name server.
- Routers often contain static address to name mappings local to the
- router, so both the DNS zone files and the router configurations will
- need to be checked.
-
- What we first want to do is generate a list of name/address mappings,
- the mapping mechanism for each instance (e.g., static entry in
- configuration file, RR in our zone's DNS, RR in a zone file outside
- ours), the definition statement (or equivalent if the routers are
- configured with SNMP), and current IP address. We then want to
- compare the addresses in this list to the list defined earlier of
- prefixes affected by renumbering. The intersection of these lists
- define where we need to make changes.
-
- Note that the explicit definition statement, or at leasts its
- variables, should be kept. In the real world, static IP address
- mappings in hosts may not have been maintained as systematically as
- are RR records in a DNS server. It is entirely possible that
- different host mapping entries for the same name point to different
- addresses.
-
- 7.3.1 DNS Tools
-
- The DNS itself can both delay and and speed router renumbering.
- Caches in DNS servers both inside and outside the organization may
- have sufficient persistence that a "flag day" cutover is not
- practical if worldwide connectivity is to be kept. DNS can help,
- however, make a period of old and new address coexistence work.
-
- If, for example, a given router interface may have a coexisting new
- and old address, it can be appropriate to introduce the new address
- as a CNAME alias for the new address.
-
-
-
- Berkowitz Informational [Page 28]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- DNS RR statements can end with a semicolon, indicating the rest of
- the line is a comment. This can be used as the basis of tools to
- renumber DNS names for router addresses, by putting a comment (e.g.,
- ";newaddr") at the end of the CNAME statements for the new addresses.
- At an appropriate time, a script could generate a new zone file in
- which the new addresses become the primary definitions on A records,
- and the old addresses could become appropriately commented CNAME
- records. At a later time, these commented CNAME entries could be
- removed.
-
- Care should be taken to assure that PTR reverse mapping entries are
- defined for new addresses, because some router vendor tools depend on
- reverse mapping.
-
- 7.3.2 Related name tools
-
- Especially on UNIX and othe that do routing, there may be static name
- definitions. Such definitions are probably harder to keep maintained
- than entries in the DNS, simply because they are more widely
- distributed.
-
- Several tools are available to generate more maintainable entries. A
- perl script called h2n converts host tables into zone data files that
- can be added to the DNS server. It is available as
- ftp://ftp.uu.net/published/oreilly/nutshell/dnsbind/dns.tar.Z.
- Another tool, makezones, is part of the current BIND distribution,
- and can also be obtained from
- ftp://ftp.cus.cam.ac.uk/pub/software/programs/DNS/makezones
-
- See the DNS Resources Directory at http://www.dns.net/dnsrd.
-
- 8. Router Identifiers
-
- Configuration commands in this category assign IP addresses to
- physical or virtual interfaces on a single router. They also include
- commands that assign IP-address-related information to the router
- "box" itself, and commands which involve the router's interaction
- with neighbors below the full routing level (e.g., default gateways,
- ARP).
-
- Routers may have other unique identifiers, such as DNS names used for
- the set of addresses on the "box," or SNMP systemID strings.
-
- 8.1. Global Router Identification
-
- Traditional IP routers do not have unique identifiers, but rather are
- treated as collections of IP addresses associated with their
- interfaces. Some protocol mechanisms, notably OSPF and BGP, need an
-
-
-
- Berkowitz Informational [Page 29]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- address for the router itself, typically to establish tunnel
- endpoints between peer routers. Other applications include
- "unnumbered interfaces" used to conserve address space for serial
- media, a practice discussed further below.
-
- In the illustration below, the 10.1.0.0/16 address space is used for
- global identifiers. A TCP tunnel runs from 10.1.0.1 to 10.1.0.2, but
- its traffic is load-shared among the two real links, 172.31.1.0 and
- 172.31.2.0.
-
- 172.31.4.1/24 172.31.5.1/24
- | |
- | |
- +-------------------------------------+
- | Router 1 |
- | |
- | 10.1.0.1/16 |
- | # |
- +-------------------#-----------------+
- | 172.31.1.1/24 # | 172.31.2.1/24
- | # |
- | # |
- | # |
- | # |
- | # |
- | # |
- | 172.31.1.2/24 # | 172.31.2.2/24
- +-------------------#-----------------+
- | Router 2 |
- | |
- | 10.1.0.2/16 |
- | |
- +-------------------------------------+
- | |
- | |
- 172.31.5.1/24 172.31.6.1/24
-
-
- A common practice to provide router identifiers is using the "highest
- IP address" on the router as an identifier for the "box." Many
- implementations have a default mechanism to establish the router ID,
- which may be the highest configured address, or the highest active
- address.
-
-
-
-
-
-
-
-
- Berkowitz Informational [Page 30]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- Typical applications of a global router ID may not require it be a
- "real" IP address that is advertised through the routing domain, but
- is simply a 32-bit identifier local to each router. When this is the
- case, this identifier can come from the RFC 1918 private address
- space rather than the enterprise's registered address space.
-
- Allowing default selection of the router ID can be unstable and is
- not recommended. Most implementations have a means of declaring a
- pseudo-IP address for the router itself as opposed to any of its
- ports.
-
- Changes to this pseudo-address may have implications for DNS. Even
- if this is not a real address, A and PTR resource records may have
- been set up for it, so diagnostics can display names rather than
- addresses.
-
- Another potential DNS implication is that a CNAME may have been
- established for the entire set of interface addresses on a router.
- This allows testing, telnet, etc., to the router via any reachable
- path.
-
- 8.2 Interface Address
-
- Interface addresses are perhaps the most basic place to begin router
- renumbering. Interface configuration will require an IP address, and
- usually a subnet mask or prefix length. Some implementations may not
- have a subnet mask in the existing configuration, because they use a
- "default mask" based on a classful assumption about the address. Be
- aware of possible needs for explicit specification of a subnet mask
- or other prefix length specification when none previously was
- specified. This will be especially common on older host-based
- routers.
-
- Multiple IP addresses, in different subnets, can be assigned to the
- same interface. This is often a valuable technique in renumbering,
- because the router interface can be configured to respond to both the
- new and old addresses.
-
- Caution is necessary, however, in using multiple subnet addresses on
- the same interface. OSPF and IS-IS implementations may not advertise
- the additional addresses, or may constrain their advertisement so all
- must be in the same area.
-
-
-
-
-
-
-
-
-
- Berkowitz Informational [Page 31]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- When this method is used to make the interface respond to new and old
- addresses, and the renumbering process is complete, care must be
- taken in removing the old addresses. Some router implementations
- have special meaning to the order of address declarations on an
- interface. It is highly likely that routers, or at least the
- interface, must be restarted after an address is removed.
-
- 8.3 Unnumbered Interfaces
-
- As mentioned previously, several conventions have been used to avoid
- wasting subnet space on serial links. One mechanism is to implement
- proprietary "half-router" schemes, in which the unnumbered link
- between router pairs is treated as an "internal bus" creating a
- "virtual router," such that the scope of the unnumbered interface is
- limited to the pair of routers.
-
- | +------------+ +------------+ |
- | | | | | |
- | e0 | |s0 s0 | | |
- |-------------| R1 |................| R2 |-------|
- | 192.168.1.1 | 10.1.0.1/16| | 10.1.0.2/16| |
- | /24 | | | | |
- | +------------+ +------------+
-
- In the above example, software in routers R1 and R2 automatically
- forward every packet received on serial interface S0 to Ethernet
- interface E0. They forward every packet on e0 to their local S0.
- Neither S0 has an IP address. R1 has the router ID 10.1.0.1/16 and
- R2 has 10.1.0.2/16.
-
- It is thus impossible to send a specific ping to the S0 interfaces,
- making it difficult to test whether a connectivity problem is due to
- S0 or E0. Some management is possible as long as at least one IP
- address on the router (e.g., E0) is reachable, since this will permit
- SNMP connectivity to the router. Once the router is reachable with
- SNMP, the unnumbered interface can be queried through the MIB
- ifTable.
-
- Another approach is to use the global router identifier as a pseudo-
- address for every unnumbered interface on a router. In the above
- example, R1 would use 10.1.0.1 as its identifier. This provides an
- address to be used for such functions as the IP Route Recording
- option, and for providing a next-hop-address for routes.
-
-
-
-
-
-
-
-
- Berkowitz Informational [Page 32]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- The second approach is cleaner, but still can create operational
- difficulties. If there are multiple unnumbered interfaces on a
- router, which one (if any) should/will respond to a ping? Other
- network management mechanisms do not work cleanly with unnumbered
- interface.
-
- As part of a renumbering effort, the need for unnumbered interfaces
- should be examined. If the renumbering process moves the domain to
- classless addressing, then serial links can be given addresses with a
- /30 prefix, which will waste a minimum of address space.
-
- For dedicated or virtual dedicated point-to-point links within an
- organization, another alternative to unnumbered operation is using
- RFC1918 private address space. Inter-router links rarely need to be
- accessed from the Internet unless explicitly used for exterior
- routing. External traceroutes will also fail reverse DNS lookup.
-
- If unnumbered interfaces are kept, and the router-ID convention is
- used, it will probably be more stable to rely on an explicitly
- configured router ID rather than a default from a numbered interface
- address.
-
- The situation becomes even more awkward if it is desired to use
- unnumbered interfaces over NBMA services such as Frame Relay. OSPF,
- for example, uses the IP address of numbered interfaces as a unique
- identifier for that interface. Since unnumbered interfaces do not
- have their own unique address, OSPF has not obvious way to identify
- these interfaces. A physical index (e.g., ifTable) could be used,
- but would have to be extended to have an entry for each logical entry
- (i.e., VC) multiplexed onto the physical interface.
-
- 8.4 Address Resolution
-
- While mapping of IP addresses to LAN MAC addresses is usually done
- automatically by the router software, there will be cases where
- special mappings may be needed. For example, the MAC address used by
- router interfaces may be locally administered (i.e., set manually),
- rather than relying on the burnt-in hardware address. It may be part
- of a proprietary method that dynamically assigns MAC addresses to
- interfaces. In such cases, an IP address may be part of the MAC
- address configuration statements and will need to be changed.
-
-
-
-
-
-
-
-
-
-
- Berkowitz Informational [Page 33]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- Manual mapping to medium addresses will usually be needed for NBMA
- and switched media. When renumbering IP addresses, statements that
- map the IP address to frame relay DLCIs, X.121 addresses, SMDS and
- ATM addresses, telephone numbers, etc., will need to be changed to
- the new address. Local requirements may require a period of parallel
- operation, where the old and new IP addresses map to the same medium
- address.
-
- 8.5 Broadcast Handling
-
- RFC1812 specifies that router interfaces MUST NOT forward limited
- broadcasts (i.e., to the all-ones destination address,
- 255.255.255.255). It is common, however, to have circumstances where
- a LAN segment is populated only by clients that communicate with key
- servers (e.g., DNS or DHCP) by sending limited broadcasts. Router
- interfaces can cope with this situation by translating the limited
- broadcast address to a directed broadcast address or a specific host
- address, which is legitimate to forward.
-
- When limited address translation is done for serverless segments, and
- the new target address is renumbered, the translation rule must be
- reconfigured on every interface to a serverless segment. Be sure to
- recognize that a given segment might have a server from the
- perspective of one service (e.g., DHCP), but could be serverless for
- other services (e.g., NFS or DNS).
-
- 8.6 Dynamic Addressing Support
-
- Routers can participate in dynamic addressing with RARP, DHCP, BOOTP,
- or PPP. In a renumbering effort, several kinds of changes may made
- to be made on routers participating in dynamic addressing.
-
- If the router acts as a server for dynamic address assignment, the
- addresses it assigns will need to be renumbered. These might be
- specific addresses associated with MAC addresses or dialup ports, or
- could be a pool of addresses. Pools of addresses may be seen in pure
- IP environments, or in multiprotocol situations such as Apple MacIP.
-
- If the router does not assign addresses, it may be responsible for
- forwarding address assignment requests to the appropriate server(s).
- If this is the case, there may be hard-coded references to the IP
- addresses of these servers, which may need to be changed as part of
- renumbering.
-
-
-
-
-
-
-
-
- Berkowitz Informational [Page 34]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- 9. Filtering and Access Control
-
- Routers may implement mechanisms to filter packets based on criteria
- other than next hop destination. Such mechanisms often are
- implemented differently for unicast packets (the most common case) or
- for multicast packets (including routing updates). Filtering rules
- may contain source and/or destination IP addresses that will need to
- change as part of a renumbering effort.
-
- Filtering can be done to implement security policies or to control
- traffic. In either case, extreme care must be taken in changing the
- rules, to avoid leakage of sensitive information. denial of access
- to legitimate users, or network congestion.
-
- Routers may implement logging of filtering events, typically denial
- of access. If logging is implemented, logging servers to which log
- events are sent preferably should be identified by DNS name. If the
- logging server is referenced by IP address, its address may need to
- change during renumbering. Care should be taken that critical
- auditing data is not lost during the address change.
-
- 9.1 Static Access Control Mechanisms
-
- Router filters typically contain some number of include/exclude rules
- that define which packets to include in forwarding and which to
- exclude. These rules typically contain an address argument and some
- indication of the prefix length. This length indication could be a
- count, a subnet mask, or some other mask.
-
- When renumbering, the address argument clearly has to change. It can
- be more subtle if the prefix length changes, because the length
- specification in the rule must change as well. Needs for such changes
- may be hard to recognize, because they apply to ranges of addresses
- that might be at a level of aggregation above the explicit
- renumbering operation.
-
- RFC 1812 requires that address-based filtering allow arbitrary prefix
- lengths, but some hosts and routers might only allow classful
- prefixes.
-
-
-
-
-
-
-
-
-
-
-
-
- Berkowitz Informational [Page 35]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- 9.2 Special Firewall Considerations
-
- Routers are critical components of firewall systems.
- Architecturally, two router functions are described in firewall
- models, the external screening router between the outside and the
- "demilitarized zone (DMZ)," and the internal screening router between
- the inside and the "perimeter network." Between these two networks
- is the bastion host, in which reside various non-routing isolation
- and authentication functions, beyond the scope of this document.
-
- One relevant aspect of the bastion host, however, is that it may do
- address translation or higher-layer mappings between differnt address
- spaces. If the "outside" address space (i.e., visible to the
- Internet) changes, this will mean that the outside screening router
- will need configuration changes. Since the outside screening router
- may be under the control of the ISP rather than the entrerprise,
- administrative coordination will be needed.
-
- DMZ +--------+ Peri-
- |---| Public | meter
- +-----------+ | | Hosts | | +-----------+
- From | External | | +--------+ |---| Internal |
- Internet...| Screening |---| +--------+ | | Screening |
- | Router | |---| Bastion|------| | Router |....To
- +-----------+ | | Host | | +-----------+ Internal
- | +--------+ | +-----------+ Network
- | +--------+ |---| Dialup |
- |---| Split | | | Access |
- | | DNS | | | Server |
- | +--------+ | +-----------+
-
- External screening routers typically have inbound access lists that
- block unauthorized traffic from the Internet, and outbound access
- lists that permit access only to DMZ servers and the bastion host.
- The inbound filters commonly block the Private Address Space, as well
- as address space from the enterprise's internal network. If the
- internal network address changes, the inbound filters clearly will
- need to change.
-
- If DMZ host addresses change, the corresponding outbound filters from
- the external screening host also will need to change. Internal
- screening routers permit access from the internal network to selected
- servers on the perimeter network, as well as to the bastion host
- itself. If the enterprise uses private address space internally,
- renumbering may not affect this router.
-
-
-
-
-
-
- Berkowitz Informational [Page 36]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- Another component of a firewall system is the "split DNS" server,
- which provides address mapping in relation to the globally visible
- parts of the
-
- 9.3 Dynamic Access Control Mechanisms
-
- Certain access control services, such as RADIUS and TACACS+, may
- insert dynamically assigned access rules into router configurations.
- For example, a RADIUS database "contains a list of requirements which
- must be met to allow access for the user. This always includes
- verification of the password, but can also specify the client(s) or
- port(s) to which the user is allowed access. [Rigney]."
-
- Configuration information dynamically communicated to the router may
- be in the form of filtering rules. Effectively, this authentication
- database becomes an extension of the router configuration database.
- Both these databases may need to change as part of a renumbering
- effort.
-
- Another dynamic configuration issue arises when "stateful packet
- screening" on bastion hosts or routers is used to provide security
- for UDP-based services, or simply for IP. In such services, when an
- authorized packet leaves the local environment to go into an
- untrusted address space, a temporary filtering rule is established on
- the interface on which the response to this packet is expected. The
- rule typically has a lifetime of a single packet response. If these
- rules are defined in a database outside of the router, the rule
- database again is an extension of router configuration that must be
- part of the renumbering effort.
-
- 10. Interior Routing
-
- This section deals with routing inside an enterprise, which generally
- follows, ignoring default routes, the rules:
-
- 1. Does a single potential route exist to a destination?
- If so, use it.
- 2. Is there more than one potential path to a destination?
- If so, use the path with the lowest end-to-end metric.
- 3. Are there multiple paths with equal lowest cost to the
- destination? If so, consider load balancing.
-
- Most enterprises do not directly participate in global Internet
- routing mechanisms, the details of which are of concern to their
- service providers. The next section deals with those more complex
- exterior mechanisms.
-
-
-
-
-
- Berkowitz Informational [Page 37]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- 10.1 Static Routes
-
- During renumbering, the destination and/or next hop address of static
- routes may need to change. It may be necessary to restart routers or
- explicitly clear a routing table entry to force the changed static
- route to take effect.
-
- 10.2 RIP (Version 1 unless otherwise specified)
-
- The Routing Information Protocol (RIP) has long been with us, as one
- of the first interior routing protocols. It still does that job in
- small networks, and also has been used for assorted functions that
- are not strictly part of interior routing. In this discussion, we
- will first deal with pure interior routing applications.
-
- In a renumbering effort that involves classless addressing, RIPv1 may
- not be able to cope with the new addressing scheme. Officially, this
- protocol is Historic and should be avoided in new routing plans.
- Where legacy support requirements dictate it be retained, it is
- worthwhile to try to limit RIPv1 in "stub" parts of the network.
- Vendor-specific mechanisms may be available to interface RIPv1 to a
- classless environment.
-
- As part of planning renumbering, strong consideration should be given
- to moving to RIPv2, OSPF, or other classless routing protocols as the
- primary means of interior routing. Doing so, however, may not remove
- the need to run RIP in certain parts of the enterprise.
-
- RIP is widely implemented on hosts, where it may be used as a method
- of router discovery, or for load-balancing and fault tolerance when
- multiple routers are on a subnet. In these applications, RIP need
- not be the only routing protocol in the domain; RIP may be present
- only on stub subnets. Destination information from more capable
- routing protocols may be translated into RIP updates. While it is
- generally reasonable to minimize or remove RIP as part of a
- renumbering effort, be careful not to disable the ability of hosts to
- locate routers.
-
- RIP is also used as a quasi-exterior routing mechanism between some
- customers and their ISPs, as a means simpler than BGP for the
- customer to announce routes to the provider.
-
- 10.3 OSPF
-
- OSPF has several sensitivities to renumbering beyond those of simpler
- routing protocols. If router IDs are assigned to be part of the
- registered address space, they may need to be changed as part of the
- renumbering effort. It may be appropriate to use RFC 1918 private
-
-
-
- Berkowitz Informational [Page 38]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- address space for router IDs, as long as these can be looked up in a
- DNS server within the domain.
-
- Summarization rules are likely to be affected by renumbering,
- especially if area boundaries change.
-
- Special addressing techniques, such as unnumbered interfaces and
- physical interfaces with IP addresses in multiple subnets, may not be
- transparent to OSPF. Care should be exercised in their use, and
- their use definitely should be limited to intra-area scope.
-
- If part of the renumbering motivation is the introduction of NBMA
- services, there can be numerous impacts on OSPF. Generally, the best
- way to minimize impact is to use separate subnets for each VC. By
- doing so, different OSPF costs can be assigned to different VCs,
- designated router configuration is not needed, etc.
-
- 10.4 IS-IS
-
- IP prefixes are usually associated with IS-IS area definitions. If
- IP prefixes change, there may be a corresponding change in area
- definitions.
-
- 10.5 IGRP and Enhanced IGRP
-
- When a change from IGRP to enhanced IGRP is part of a renumbering
- effort, the need to disable IGRP automatic route summarization needs
- to be considered. This is likely if classless addressing is being
- implemented.
-
- Also be aware of the nuances of automatic redistribution between IGRP
- and EIGRP. The "autonomous system number," which need not be a true
- AS number but simply identifies a set of cooperating routers, must be
- the same on the IGRP and EIGRP processes for automatic redistribution
- to occur.
-
- 11. Exterior Routing
-
- Exterior routes may be defined statically. If dynamic routing is
- involved, such routes are learned primarily from BGP. RIP is not
- infrequently used to allow ISPs to learn dynamically of new customer
- routes, although there are security concerns in such an approach.
- IGRP and EIGRP can be used to advertise external routes.
-
-
-
-
-
-
-
-
- Berkowitz Informational [Page 39]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- Renumbering that affects BGP-speaking routers can be complex, because
- it can require changes not only in the BGP routers of the local
- Autonomous System, but also require changes in routers of other AS
- and in routing registries. This will require careful administrative
- coordination.
-
- If for no other reason than documentation, consider use of a routing
- policy notation [RIPE-181++] [RPSL] to describe exterior routing
- policies
-
- 11.1 Routing Registries/Routing Databases
-
- Organizations who participate in exterior routing usually will have
- routing information not only in their routers, but in databases
- operated by registries or higher-level service providers (e.g., the
- Routing Arbiter).
-
- If an ISP whose previous address space came from a different provider
- either renumbers into a different provider's address space, or gains
- a recognized block of its own, there may be administrative
- requirements to return the previously allocated addresses. These
- include changes in IN-ADDR.ARPA delegation, SWIP databases, etc., and
- need to be coordinated with the specific registries and providers
- involved. Not all registries and providers have the same policies.
-
- If the enterprise is a registered Autonomous System and renumbers
- into a different address space, route objects with old prefixes in
- routing registries need to be deleted and route objects with new
- prefixes need to be added.
-
- 11.2 BGP--Own Organization
-
- IP addressing information can be hard-coded in several aspects of a
- BGP speaker. These include:
-
- 1. Router ID
- 2. Peer router IP addresses
- 3. Advertised prefix lists
- 4. Route filtering rules
-
- Some tools exist [RtConfig] for generating policy configuration part
- of BGP router configuration statements from the policies specified in
- RIPE-181 or RPSL.
-
-
-
-
-
-
-
-
- Berkowitz Informational [Page 40]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- 11.3 BGP--Other AS
-
- Other autonomous systems, including nonadjacent ones, can contain
- direct or indirect (e.g., aggregated) references to the above routing
- information. Tools exist that can do preliminary checking of
- connectivity to given external destinations [RADB].
-
- 12. Network Management
-
- This section is intended to deal with those parts of network
- management that are intimately associated with routers, rather than a
- general discussion of renumbering and network management.
-
- Methods used for managing routers include telnets to virtual console
- ports, SNMP, and TFTP. Network management scripts may contain hard-
- coded references to IP addresses supporting these services. In
- general, try to convert script references to IP addresses to DNS
- names.
-
- A critical and complex problem will be converting SNMP databases,
- which are usually organized by IP address.
-
- 12.1 Configuration Management
-
- Names and addresses of servers that participate in configuration
- management may need to change, as well as the contents of the
- configurations they provide. TFTP servers are commonly used here, as
- may be SNMP managers.
-
- 12.2 Name Resolution/Directory Services
-
- During renumbering, it will probably be useful to assign DNS names to
- interfaces, virtual interfaces, and router IDs of routers. Remember
- that it is perfectly acceptable to identify internal interfaces with
- RFC1597/RFC1918 private addresses, as long as firewalling or other
- filtering prevent these addresses to be propagated outside the
- enterprise.
-
- If dynamic addressing is used, dynamic DNS should be considered.
- Since this is under development, it may be appropriate to consider
- proprietary means to learn what addresses have been assigned
- dynamically, so they can be pinged or otherwise managed.
-
- Also remember that some name resolution may be done by static tables
- that are part of router configurations. Changing the DNS entries,
- and even restarting the routers, will not change these.
-
-
-
-
-
- Berkowitz Informational [Page 41]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- 12.3 Fault Management
-
- Abnormal condition indications can be sent to several places that may
- have hard-coded IP addresses, such as SNMP trap servers, syslogd
- servers, etc.
-
- It should be remembered that large bursts of transient errors may be
- caused as part of address cutover in renumbering. Be aware that
- these bursts might overrun the capacity of logging files, and
- conceivably cause loss of auditing information. Consider enlarging
- files or otherwise protecting them during cutover.
-
- 12.4 Performance Management
-
- Performance information can be recorded in routers themselves, and
- retrieved by network management scripts. Other performance
- information may be sent to syslogd, or be kept in SNMP data bases.
-
- Load-generating scripts used for performance testing may contain
- hard-coded IP addresses. Look carefully for scripts that contain
- executable code for generating ranges of test addresses. Such
- scripts may, at first examination, not appear to contain explicit IP
- addresses. They may, for example, contain a "seed" address used with
- an incrementing loop.
-
- 12.5 Accounting Management
-
- Accounting records may be sent periodically to syslogd or as SNMP
- traps. Alternatively, the SNMP manager or other management
- applications may periodically poll accounting information in routers,
- and thus contain hard-coded IP addresses.
-
- 12.6 Security Management
-
- Security management includes logging, authentication, filtering, and
- access control. Routers can have hard-coded references to servers
- for any of these functions.
-
- In addition, routers commonly will contain filters containing
- security-related rules. These rules are apt to need explicit
- recoding, since they tend to operate on a bit level.
-
- Some authentication servers and filtering mechanisms may dynamically
- update router filters.
-
-
-
-
-
-
-
- Berkowitz Informational [Page 42]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- 12.7 Time Service
-
- Hard-coded references to NTP servers should be changed to DNS when
- possible, and renumbered otherwise.
-
- 13. IP and Protocol Encapsulation
-
- IP packets can be routed to provide connectivity for non-IP
- protocols, or for IP traffic with addresses not consistent with the
- active routing environment. Such encapsulating functions usually
- have a tunneling model, where an end-to-end connection between two
- "passenger" protocol addresses is mapped to a pair of endpoint IP
- addresses. Generic Route Encapsulation is a representative means of
- such tunneling [RFC1701, RFC1702].
-
- 13.1 Present
-
- Renumbering of the primary IP environment often does not mean that
- passenger protocol addresses need to change. In fact, such protocol
- encapsulation for IP traffic may be a very viable method for handling
- legacy systems that cannot easily be renumbered. For this legacy
- case, the legacy IP addresses can be tunneled over the renumbered
- routing environment.
-
- Also note that IP may be a passenger protocol over non-IP systems
- using IPX, AppleTalk, etc.
-
- 13.2 Future
-
- Tunneling mechanisms are fundamental for the planned transition of
- IPv4 to IPv6. As part of an IPv4 renumbering effort, it may be
- worthwhile to reserve some address space for future IPv6 tunnels.
-
- While there are clear and immediate needs for IPv4 renumbering, there
- may be cases where IPv4 renumbering can be deferred for some months
- or years. If the effort is deferred, it may be prudent at that time
- to consider if available IPv6 implementations or tunneling mechanisms
- form viable alternatives to IPv4 renumbering. It might be
- appropriate to renumber certain parts of the existing IPv4 space
- directly into the IPv6 space. Tools for this purpose are
- experimental at the time this document was written.
-
-
-
-
-
-
-
-
-
-
- Berkowitz Informational [Page 43]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- 14. Security Considerations
-
- Routers are critical parts of firewalls, and are otherwise used for
- security enforcement. Configuration errors made during renumbering
- can expose systems to malicious intruders, or deny service to
- authorized users. The most critical area of concern is that filters
- are configured properly for old and new address, but other numbers
- also can impact security, such as pointers to authentication,
- logging, and DNS servers.
-
- During a renumbering operation, it may be appropriate to introduce
- authentication mechanisms for routing updates.
-
- 15. Planning and Implementing the Renumbering
-
- Much of the effort in renumbering will be on platforms other than
- routers. Nevertheless, routers are a key part of any renumbering
- effort.
-
- Step 1--Inventory of affected addresses and names.
-
- Step 2--Design any needed topological changes. If temporary address
- space, network address translators, etc., are needed, obtain
- them.
-
- Step 3--Install and test changes to make the network more
- renumbering-friendly. These include making maximum use of
- default routes and summarization, while minimizing address-
- based references to servers.
-
- Step 4--Plan the actual renumbering. Should it be phased or total?
- Can it be done in a series of stub network renumberings,
- possibly with secondary addresses on core routers? Is NAT
- appropriate? If so, how is it to be used?
-
- What is your plan of retreat if major problems develop?
- Make a distinction between problems in the routing system
- and unforeseen problems in hosts affected by renumbering.
-
- Step 5--Take final backups.
-
-
-
-
-
-
-
-
-
-
-
- Berkowitz Informational [Page 44]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- Step 6--Cut over addresses and names, or begin coexistence.
-
- Make needed DNS and firewall changes.
- Restart routers and servers as appropriate.
- Clear caches as appropriate.
- Remember static name definitions in routers may not be affected
- by DNS changes.
- Coordinate changes with affected external organizations (e.g.,
- ISPs, business partners, routing registries)
-
- Step 6--Document what isn't already documented. Make notes to help
- the person who next needs to renumber. Share experience with
- the PIER working group or other appropriate organizations.
-
- 15.1 Applying Changes
-
- Renumbering changes should be introduced with care into operational
- networks. For changes to take effect, it is likely that at least
- interfaces and probably routers will have to be restarted. The
- sequence in which changes are applied must be carefully thought out,
- to avoid loss of connectivity, routing loops, etc., while the
- renumbering is in process.
-
- See case studies presented to the PIER Working Group for examples of
- operational renumbering experience. Organizations that have
- undergone renumbering have had to pay careful attention to informing
- users of possible outages, coordinating changes among multiple sites,
- etc. It will be an organization-specific decision whether router
- renumbering can be implemented incrementally or must be done in a
- major "flag day" conversion.
-
- Before making significant changes, TAKE BACKUPS FIRST of all router
- configuration files, DNS zone files, and other information that
- documents your present environment.
-
- 15.2 Configuration Control
-
- Operationally, an important part of renumbering and continued
- numbering maintenance is not to rely on local router interfaces,
- either command language interpreter, menu-based, or graphic, for the
- more sophisticated aspects of configuration, but to do primary
- configuration (and changes) on an appropriate workstation. On a
- workstation or other general-purpose computer, configuration files
- can be edited, listed, processed with macro processors and other
- tools, etc. Source code control tools can be used on the router
- configuration files.
-
-
-
-
-
- Berkowitz Informational [Page 45]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- Once the configuration file is defined for a router, mechanisms for
- loading it vary with the specific router implementation. In general,
- these will include a file transfer using FTP or TFTP into a
- configuration file on the router, SNMP SET commands, or logging in to
- the router as a remote console and using a terminal emulator to
- upload the new configuration under the router's interactive
- configuration mode. Original acquisition of legacy configuration
- files is the inverse of this process.
-
- 15.3 Avoiding Instability
-
- Routing processes tend towards instability when they suddenly need to
- handle very large numbers of updates, as might occur if a "flag day"
- cutover is not carefully planned. A general guideline is to make
- changes in only one part of a routing hierarchy at a time.
-
- Routing system design should be hierarchical in all but the smallest
- domains. While OSPF and IS-IS have explicit area-based hierarchical
- models, hierarchical principles can be used with most implementations
- of modern routing protocols. Hierarchy can be imposed on a protocol
- such as RIPv2 or EIGRP by judicious use of route aggregation, routing
- advertisement filtering, etc.
-
- Respecting a hierarchical model during renumbering means such things
- as renumbering a "stub" part of the routing domain and letting that
- part stabilize before changing other parts. Alternatively, it may be
- reasonable to add new numbers to the backbone, allowing it to
- converge, renumbering stubs, and then removing old numbers from the
- backbone. Obviously, these guidelines are most practical when there
- is a distinct old and new address space without overlaps. If a block
- of addresses must simply be reassigned, some loss of service must be
- expected.
-
- 16. Acknowledgments
-
- Thanks to Jim Bound, Paul Ferguson, Geert Jan de Groot, Roger Fajman,
- Matt Holdrege, Dorian Kim, Walt Lazear, Eliot Lear, Will Leland, and
- Bill Manning for advice and comments.
-
-
-
-
-
-
-
-
-
-
-
-
-
- Berkowitz Informational [Page 46]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- 17. References
-
- [RFC2071] Ferguson, P., and H. Berkowitz, "Network Renumbering
- Overview: Why would I want it and what is it anyway?", RFC 2071,
- January 1997.
-
- [Cansever] Cansever, D., "NHRP Protocol Applicability Statement",
- Work in Progress.
-
- [Katz] Luciani, J., Katz, D., Piscitello, D., and Cole, B., "NBMA Next
- Hop Resolution Protocol (NHRP)", Work in Progress.
-
- [Hubbard] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and J.
- Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES", BCP 12, RFC
- 2050, November 1996.
-
- [RFC1631] Egevang,, K., and P. Francis, "The IP Network Address
- Translator (NAT)", RFC 1631, May 1994.
-
- [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G-J.,
- and E. Lear, "Address Allocation for Private Internets", RFC 1918,
- February 1996.
-
- [RFC1900] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", RFC
- 1900, February 1996.
-
- [RPS] Alaettinoglu, C., Bates, T., Gerich, E., Terpstra, M., and C.
- Villamizer, "Routing Policy Specification Language", Work in Progress.
-
- [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
- 1812, June 1995.
-
- [Rigney] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote
- Authentication Dial In User Service (RADIUS)", RFC 2058, January 1997.
-
- [Carpenter] Message to PIER Mailing List, see PIER Archives
-
- [Lear] Message to PIER Mailing List, see PIER Archives
-
- [deGroot] Message to PIER Mailing List, see PIER Archives
-
- [Wobus] "DHCP FAQ Memo",
- http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html
-
-
-
-
-
-
-
-
- Berkowitz Informational [Page 47]
-
- RFC 2072 Router Renumbering Guide January 1997
-
-
- 18. Author's Address
-
- Howard C. Berkowitz
- PSC International
- 1600 Spring Hill Road, Suite 310
- Vienna VA 22182
-
- Phone: +1 703 998 5819
- EMail: hcb@clark.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Berkowitz Informational [Page 48]
-
-